今天如果遇到發版後突然發現的 bug，需要回到上一版，這時候能不能在短時間內回到還沒發生問題的版本就很重要，這也就是版本控制的重要性。

要可以實現有規矩的版本控制，Git Flow 就是其中重要的規則。

Git Flow 中的分支們

前面的文章有說到如果有多位工程師同時在開發，大家就像是從主要的枝幹中先分出小支幹，各自開發完後，再把血好的枝幹匯回主枝幹，而主枝幹的名稱一般稱作 Master/Main Branch。在這邊的程式碼，就是已經測試完成，準備可以上線的。

而 從 Master 引流出來的分支，就是 Develop Branch，已經合併到這邊的分支就可以進行測試。當今天工程師要開發一項功能的時候，就從 Develop Branch 再引流出 Feature Branch，當開發完成時，在匯流到Develop Branch 準備測試。

程式碼如果在 Develop Branch 進行單元測試等完成後，準備發佈新版本前，會再分出 Release Branch，讓 QA 測試工程師們進行最後的把關跟修復，在這裡，除了修復 bug 之外，不會接受新功能的併入。

最後，在 Release Branch 完成測試及修復後，就會匯回 Master 準備上線，而在 Release Branch 上有作修改的，也會匯回 Develop Branch，以確保 Develop Branch 擁有修復後的版本。

而在 Master 上的程式碼，也都會加上各發佈版本對應的標籤（tag），當有問題需要退版或查詢功能的時候可以回溯。

程式碼上線後，如果發現緊急需要修復的 bug，則會直接從主分支直接分流出 Hotfix Branch，修復完後再直接匯回 Master 進行上線，也會同步在 Develop Branch。

Git Flow 的好處

這樣一層一層依照階段及特性將程式標記及設立流程最大的好處，就在於可以快速找到不同時間點的版本紀錄，也可以快速的回溯到特定的版本，也可以知道目前開發的進度到哪裡，在上線前還有哪些流程需要跑完。

有各種分支的好處也在於可以讓工程師們在各個階段獨立開發，開發完後申請合併時，也會進行程式碼的檢查，需要通過審核後才會合併，對於程式的品質也多了把關。

以 PM 的角度，為了可以快速上版，也可以將每次發布的功能切小，控制在一定的範圍內，達到小步快跑的目標。